Snyk で間接的な依存関係のセキュリティを確保
Snyk Open Source は、直接的な依存関係と間接的な依存関係両方の脆弱性を検出して修正します。
このレポートでは、ソフトウェア開発におけるセキュリティツール、プラクティス、テクノロジーの導入、および自動化と人工知能 (AI) の影響について考察します。
パート 1
コードが変更される頻度が高いほど、サプライチェーンの脆弱性のリスクは大きくなり、短期間でパッチを適用しなければならなくなります。当社の調査によると、80% の組織が毎日または毎週コードをリリースしていますが、それはおそらく、その複雑さと依存構造から定期的に更新する必要がある、オープンソースのアプリケーションやライブラリをベースとするモジュール方式のコードアーキテクチャへの移行が進んでいることを示しています。また当社の調査では、重大なオープンソースの脆弱性を 1 日以内に修正できる組織と数時間以内に修正できる組織の割合が、それぞれ 66% と 27% であることが明らかになりました。その一方、継続的にコードの脆弱性を監査している組織と毎日コードを監査している組織の割合は、それぞれわずか 27% と 28% だったため、まだ改善の余地はあります。今ではゼロデイ脆弱性の数が増加しつつあるため、継続的に、または高い頻度で監査を行えば安全性が向上します。
毎日
134
毎週
199
毎月
53
四半期に 1 回
14
わからない
4
サイバー攻撃の件数が毎年過去最高を更新し、オープンソースコードに的を絞った攻撃の数が増え続けているにもかかわらず、回答があった組織の多くは、いまだにソフトウェアコンポジション解析 (SCA、オープンソースの依存関係に対処するテクノロジー) と静的アプリケーションセキュリティテスト (SAST、オープンソースコードやプロプライエタリコードの非公開実装に対処するテクノロジー) という 2 つの最も基本的なサプライチェーンセキュリティテクノロジーを使用していません。また、Infrastructure as Code ツールの設定チェックやシークレットスキャンなどのクラウドネイティブのセキュリティ対策の導入数は、それらをさらに下回っています。
300
200
100
0
0
100
200
300
ソフトウェアコンポジション解析 (SCA)
静的コード解析/静的アプリケーションセキュリティテスト (SAST)
自動パッケージ管理
依存関係解析
ライセンススキャン
シークレット管理
設定チェック
それ以外
ソフトウェアコンポジション解析 (SCA)
静的コード解析/静的アプリケーションセキュリティテスト (SAST)
自動パッケージ管理
依存関係解析
ライセンススキャン
シークレット管理
設定チェック
それ以外
オープンソースパッケージのセキュリティ態勢の確認は、ソフトウェアサプライチェーンセキュリティを維持するうえできわめて重要であり、パッケージがセキュリティのベストプラクティスに従っていることを確認する、Snyk Advisor や OpenSSF Scorecard などの自動化されたシステムは、プログラムでリスクを解析するための最も信頼性の高い方法です。ただし、これらのシステムは、オープンソースパッケージの安全性を確認する方法としては最も人気がなく、Snyk Advisor を使用している調査回答者とセキュリティスコアカードを使用している調査回答者の割合は、それぞれわずか 40% と 34% にすぎません。
驚いたことに、すべてのパッケージに (使用されているパッケージの最低限の要件であるべき)「責任ある開示」ポリシーが設けられていることを確認している調査回答者は、わずか 52% となっています。
300
200
100
0
0
100
200
300
レジストリやパッケージマネージャーの情報を使用している
Snyk Advisor のようなツールを使用している
リポジトリの評価またはパッケージのダウンロードの統計を確認している
リリースやコミットなどの頻度を確認している
プロジェクトにアクティブなコミュニティがあることを確認している
プロジェクトに (SECURITY.md などの) 責任ある開示ポリシーが設けられていることを確認している
セキュリティスコアカードを確認している
オープンソースパッケージの安全性を確認していない
レジストリやパッケージマネージャーの情報を使用している
Snyk Advisor のようなツールを使用している
リポジトリの評価またはパッケージのダウンロードの統計を確認している
リリースやコミットなどの頻度を確認している
プロジェクトにアクティブなコミュニティがあることを確認している
プロジェクトに (SECURITY.md などの) 責任ある開示ポリシーが設けられていることを確認している
セキュリティスコアカードを確認している
オープンソースパッケージの安全性を確認していない
オープンソースセキュリティでは、サードパーティが提供するオープンソースのパッケージやライブラリの依存関係の監視がきわめて重要な課題となります。多くの組織は、セキュリティにおいて依存関係の追跡がきわめて重要であることを明確に認識しており、67% の組織が Snyk などのツールを使用して直接的な依存関係と間接的な依存関係を追跡しています。その一方、25% の組織は直接的な依存関係だけを追跡しています。間接的な依存関係を追跡すると、攻撃対象領域全体をより総合的かつ正確に把握でき、多くの場合にサプライチェーンセキュリティの隠れた弱点が明らかになります。こうした弱点は簡単に修正できないことが少なくありませんが、その理由は、直接的な依存関係から少なくともある程度の距離を置く当事者によって維持されているオープンソースのパッケージやライブラリには、ネストされた依存関係が組み込まれているという事実があるからです。
なし
23
直接のみ
103
直接 + 間接
270
わからない
8
セキュリティのシフトレフトは、積極的にコードセキュリティを強化してソフトウェアの開発中にコードに組み込まれてしまう脆弱性を減らそうとしている、多くのエンジニアリング組織の優先事項となっています。セキュリティをシフトレフトすると、導入前のテストでブロックされて修正のために開発者に戻されるビルドが減るため、SDLC のスピードと効率が向上します。自身の組織が IDE にセキュリティツールを配置していると答えた調査回答者がわずか 40% であることから、シフトレフトも完了しているとは言えず、ローカルでコマンドライン上でセキュリティツールを使用している組織の割合はさらに少ないのが実情です。 セキュリティツールが配置されている最も一般的な場所は、ビルドツールとコードリポジトリであり、いずれも約 65% となっています。
300
200
100
0
0
100
200
300
IDE
CLI
ビルドシステム
コミット前チェック
コードリポジトリ
CI/CD パイプライン
わからない
IDE
CLI
ビルドシステム
コミット前チェック
コードリポジトリ
CI/CD パイプライン
わからない
Snyk Open Source は、直接的な依存関係と間接的な依存関係両方の脆弱性を検出して修正します。
パート 2
多くの調査回答者は、ソフトウェアサプライチェーンセキュリティの危機に直面しており、さまざまな面で組織が影響を受けていると述べています。そして調査回答者の大多数が、過去 1 年以内に 1 つ以上のサプライチェーンに関する問題の影響を受けています。具体的な影響としては、53% が 1 つ以上の脆弱性にパッチを適用せざるを得なくなり、61% がオープンソースとサプライチェーンのセキュリティを確保するために新しいツールやベストプラクティスを実装しており、多くの組織がサプライチェーン攻撃の影響を直接受けて初めて対策を講じているということを示しています。
250
200
150
100
50
0
0
50
100
150
200
250
1 つ以上のサプライチェーンの脆弱性にパッチを適用しなければならなかった
サプライチェーンの脆弱性に適切に対処するために新しいツールとプラクティスを実装した
開発チームがサプライチェーンの脆弱性について深く理解できるようにトレーニングを行った
過去 1 年間にオープンソースソフトウェアサプライチェーンの脆弱性の影響を受けていない
1 つ以上のサプライチェーンの脆弱性にパッチを適用しなければならなかった
サプライチェーンの脆弱性に適切に対処するために新しいツールとプラクティスを実装した
開発チームがサプライチェーンの脆弱性について深く理解できるようにトレーニングを行った
過去 1 年間にオープンソースソフトウェアサプライチェーンの脆弱性の影響を受けていない
この結果には Log4Shell に対する一般的な対応が反映されており、組織が大幅な変更で Log4Shell に対応していることは明らかです。このインシデントを受けて、組織のコードスキャンの頻度が増えた、新しいツールを追加した、セキュアコーディングプラクティスに関する開発チームへの追加のトレーニングを行ったと答えた調査回答者の割合は、それぞれ 63%、59%、53% でした。また Log4Shell は、大部分の組織のセキュリティハイジーンを向上させたようにも思われ、58% の回答者が Log4Shell の件を受けて、必要なパッチを今までよりすばやく適用するようになったと述べています。多くの組織が必死にネストされたエクスポージャを特定してパッチを適用しようとしたため、このインシデントは短期的な大混乱を引き起こしたかもしれませんが、長期的な影響は有益であるように思われ、多くのチームがこのインシデントへの直接的な対応として、少なくともセキュリティを強化しています。
300
200
100
0
0
100
200
300
コードスキャンの頻度を増やした
開発チームに追加のトレーニングを行った
より迅速にパッチを適用した
新しいセキュリティツールを追加した
それ以外
コードスキャンの頻度を増やした
開発チームに追加のトレーニングを行った
より迅速にパッチを適用した
新しいセキュリティツールを追加した
それ以外
実際のソフトウェアサプライチェーンセキュリティに関するベストプラクティスの導入は散発的であり、正式なサプライチェーンセキュリティプログラムを有している組織は 53% にすぎません。その原因は、ソフトウェアサプライチェーンセキュリティが全般的なセキュリティプラクティスの一部とみなされているからかもしれませんが、これはサプライチェーンセキュリティが組織にとって差し迫った問題 (またはプログラムレベルでの検討や計画に値するほどの差し迫った問題) になっているのかどうかという疑問を提起します。より具体的なプラクティスの観点から言うと、SBOM を使用している組織はわずか 42%、コードの特定のためにコード署名を実装している組織は 58%、(SLSA などの) ソフトウェアライフサイクル保証プロセスを導入している組織は 62% となっています。
300
200
100
0
0
100
200
300
正式なソフトウェアサプライチェーンセキュリティプログラム
SBOM
SLSA
コード署名
定期的な監査
それ以外
正式なソフトウェアサプライチェーンセキュリティプログラム
SBOM
SLSA
コード署名
定期的な監査
それ以外
SBOM は有益なツールであるというメッセージがエンジニアリングチームやセキュリティチームに浸透しつつあるのは明らかであり、調査回答者の 42% がすでに SBOM を使用していること、また 31% が近い将来に導入を予定していることから、目覚ましい成長が予測されます。とはいえ、調査回答者は専用のサプライチェーンセキュリティシステムからだけでなく、さまざまなソフトウェア開発ツールや CI/CD ツールからも SBOM を生成していると述べています。その原因は、SBOM テクノロジーの分野で統一が取れていないからかもしれません。この分野には、今もなお (Cyclone と SPDX という) 相反する 2 つの標準があり、相互運用性の標準として認められているものはありません。これは、SBOM のバベルの塔とも言える、この分野の分断と断絶を示しているように思われます。SBOM は主にコードスキャンツールやセキュリティツール (68%) で生成されていますが、SBOM の生成に使用されるその他の一般的なシステムとしては、ビルドツール (58%)、CI/CD ツール (45%)、専用のサプライチェーンセキュリティツール (53%) などがあります。
300
200
100
0
0
100
200
300
CI/CD ツール
ビルドツール
コードスキャンおよびセキュリティツール
専用のサプライチェーンセキュリティツール
それ以外
CI/CD ツール
ビルドツール
コードスキャンおよびセキュリティツール
専用のサプライチェーンセキュリティツール
それ以外
パート 3
AI コード生成ツールは広く浸透し、今では 92% の組織で導入されています。76.5% の調査回答者は、これらのツールによって組織のコードセキュリティが強化されたと考えており、AI ツールがコードに「多くの」脆弱性をもたらしたと述べている調査回答者はわずか 14.9% にすぎません。その一方、73% は AI がコードに「ごく少数」または「ある程度」の脆弱性をもたらしたと述べています。ただし、59% の調査回答者は、AI ツールがコードにセキュリティ脆弱性をもたらすことを懸念していると述べており、50% は AI が原因でコードのライセンス違反が生じることを懸念しています。簡単に言うと、開発者は AI が数多くの新たな脆弱性をもたらすことなくコードセキュリティを強化していると考える一方、今もこのような新しいシステムに疑念を抱いています。
ほとんどない
132
ある程度
165
かなり
56
まったく
15
わからない
9
該当なし
27
多くの組織は、コードパイプラインのセキュリティ対策の一部、またはすべてを自動化しており、コードの解析は 64%、ソフトウェアアップデートの管理は 61%、テスト (ユニット、セキュリティ) は 59%、(linter、フォーマットなどの) セキュアコーディングプラクティスは 58%、コンテナとインフラストラクチャの設定のスキャンは約半数の組織で自動化されています。多くの調査回答者は、自動化されたセキュリティツールによって脆弱性レポートの誤検出率がかなり上昇したと指摘しており、60% が自動化によって誤検出が増加したと述べる一方、誤検出が減ったとする割合は 30% となっています。
増えた
246
減った
121
わからない
22
該当なし - 自動化を使用していない
15
この誤検出の割合は小さいものとは言えません。受け取った脆弱性アラートの 25% 以上が誤検出だったと述べている調査回答者と 50% 以上の脆弱性アラートに誤検出があったと述べている調査回答者の割合は、それぞれ 62% と 35% でした。このような誤検出率の高さは、脆弱性の修正率が表面上驚くほど低いように見える一因になっている可能性があります。
0 ~ 25%
139
26 ~ 50%
110
51 ~ 75%
93
76 ~ 100%
47
わからない
15
Snyk DeepCode AI は、セキュリティに特化したデータでトレーニングされた複数の AI モデルを活用します。業界をリードするセキュリティ研究者が指揮を執っているため、AI の恩恵を余すことなく享受できます。
パート 4
この分析では、(Snyk のデータに基づいて) 少なくとも 20 の組織が無視することにした脆弱性を検討しました。脆弱性や依存関係をわかりにくくすることが多い従来のコードとパッケージシステムからなる広大なエコシステムがあるため、Java が無視されている脆弱性の中で最も高い割合 (42.5%) を占めているのは驚くことではありません。当然のことながら第 2 位は、(その多くが些細な機能のためのものである) 多数のパッケージがある JavaScript となっており、無視されている脆弱性の 30.6% を占めています。第 3 位は大きく差があり、Linux ディストリビューションファミリーである Debian が 13.6% を占めています。ただ、Java と JavaScript は、数だけでなく割合でも優位を占めているため、このディストリビューションでは攻撃対象領域が過小評価されています。これらの脆弱性を無視している組織の数の観点から見ると、無視されている脆弱性の上位 34 件は、すべて Java と JavaScript となっています。
Debian
13.6%
Alpine
0.5%
Golang
3.8%
Python
6.6%
JS
30.6%
Java
42.5%
Ruby
0.2%
Ubuntu
0.5%
.NET
1.7%
組織が無視している脆弱性のタイプは、意識的に、または無意識に受け入れられている攻撃対象領域とリスクに関する有益な情報となります。少なくとも 50 のアカウントで無視されている CVE のうち、圧倒的に優勢だった脅威のタイプは、サービス拒否 (DoS) に類するものであり、これらの脆弱性は、無視されている脆弱性全体の 31.3% を占めていました。深刻ではあるものの、DoS 攻撃は多くの場合、CDN またはインフラストラクチャレベルでプロアクティブに緩和されるため、当然のことながら、多くのチームがこれらの CVE の優先度を下げています。次に、信頼できないデータのデシリアライズが 50 を超えるアカウントが無視している CVE の 14.3% を占めていました。これは、複数の言語に影響を及ぼす可能性がある比較的広範な部類の脆弱性であり、それを深刻な脆弱性に発展させる、連鎖的な攻撃や複合的な攻撃の第一歩になることが少なくありません。3 番目に多かったのはプロトタイプ汚染 (12.5%) でしたが、これは主に JavaScript コミュニティに影響を及ぼします。
リモートコード実行
3.6%
サービス拒否 (DoS)
14.3%
信頼できないデータのデシリアライズ
14.3%
プロトタイプ汚染
12.5%
情報漏洩
7.1%
正規表現によるサービス拒否 (ReDoS)
17%
ディレクトリトラバーサル
2.7%
暗号署名の不適切な検証
2.7%
任意のファイルへの書き込み
4.5%
その他
21.3%
パート 5
オープンソースの黎明期から、オープンソースソフトウェアは実際にクローズドソースソフトウェアより安全なのかどうかという議論が盛んに交わされてきました。脆弱性は、その修正プログラムと同じように公開されてオープンになるため、脆弱性データベースを使用して修正時間 (TTF) に関するデータを追跡することが可能です。当社は過去 4 年間にわたって TTF を追跡し、2019 年以降にプロプライエタリアプリケーションの TTF が着実に増加する一方、オープンソースアプリケーションの TTF が着実に減少していることに気付きました。公平のために言うと、2021 年にはどちらのジャンルの TTF も減少しましたが、当社がこのメトリックを追跡してから初めて、オープンソースアプリケーションの TTF がプロプラエタリアプリケーションの TTF を下回りました。これは、オープンソースエコシステムが時間とともにセキュリティ対応を改善し、クローズドソース環境よりセキュリティを向上させつつあることを示しています。
オープンソース
プロプライエタリ
300
200
100
0
0
100
200
300
2019 年
2020 年
2021 年
2022 年
重大な脆弱性と優先度の高い脆弱性の平均 TTF が大幅に急増するのを目の当たりにした後、平均 TTF は過去 2 年間で大幅に減少しました。この急激な変化は、その数年間でオープンソーススキャンが増加し、以前は検出されていなかった脆弱性が検出されるようになったことの表れであると考えられます。それら 2 つの重要なターゲットの平均 TTF は、2021 年から 2022 年にかけて約半分に減少し、重大な脆弱性では -51%、優先度の高い脆弱性では -49.4% になりました。このような着実な減少の理由としては、SCA などのオープンソースセキュリティツールの導入の拡大、重大なオープンソースの脆弱性の修正に向けた資金や人員の拡充、セキュリティが最優先事項となるオープンソースプロジェクトに対する認識の高まりなどが考えられます。いずれにしろ、こうした兆候は素晴らしいことであり、OSS セキュリティの継続的な改善に向けて着実に正しい方向へと進んでいることを示しています。
重大
高
中
低
1,500
1,000
500
0
0
500
1,000
1,500
2018 年
2019 年
2020 年
2021 年
2022 年
TTF はオープンソースエコシステムごとに大きく異なっていましたが、Snyk が追跡している主要なオープンソースエコシステムでは著しい減少が見られました。平均 TTF が最も減少したのは Java と Python であり、その減少率はそれぞれ 50.8% と 43.4% でした。また、減少を記録した 5 つすべてのエコシステムで 2 桁の減少が見られました。日数の観点から見て全体的な減少幅が最も大きかったのは Go と Python であり、それぞれの平均 TTF は -147 日と -115 日でした。逆に平均 TTF が増加したエコシステムは 2 つあり、C エコシステムと Ruby エコシステムは、それぞれ TTF の平均日数で 144.7% と 102.1% の増加率を示し、合計日数が +55 日と +49 日となりました。オープンソースエコシステムは、セキュリティ対応の時間を短縮するとともに、脆弱性の公開から処置までの時間を短縮することによってサプライチェーンセキュリティを強化しています。
2021 ~ 2022 年
2022 ~ 2023 年
400
300
200
100
0
0
100
200
300
400
CCP
.NET
Go
JS
Java
PHP
Python
Ruby
結論
テクノロジー組織は、この数年間でオープンソースとサプライチェーンのセキュリティを大幅に強化し、Log4Shell から教訓を得て、ツールやトレーニングを拡充させたり、スキャンの頻度を増やしたりするなど、さまざまな調整を加えてきました。その一方、オープンソースセキュリティには、まだ改善の余地がかなりあります。今もなお、多くの組織が SCA や SAST などの基本的なセキュリティテクノロジーを使用していません。オープンソースセキュリティが大きく進歩したのは明らかであり、全体として、コミュニティのセキュリティは以前より向上しています。このように、オープンソースセキュリティは大きな進歩を遂げたものの、新しいサプライチェーンセキュリティテクノロジーや成熟したサプライチェーンテクノロジーの導入、ストレスを抱えているセキュリティチームのための作業負荷の軽減や優先順位の改善、サプライチェーンセキュリティをソフトウェア開発ライフサイクルプロセスの中核的な基盤に据えるといった点でまだ改善の余地はかなりあります。
問題を無視したり、SBOM に関して混乱が生じたりすることでもたらされるリスクについて詳しく考察する、Snyk の 2023 年のオープンソースセキュリティの現状に関するレポートの全文をご覧ください。このレポートでは、OSS の進歩を促すために加えられた大幅な改善について解説します。